home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Gigarom 4
/
Mac Giga-ROM 4.0 - 1993.toast
/
FILES
/
UTI
/
A-D
/
DiskBench_1.1.cpt
/
DiskBench docs
< prev
next >
Wrap
Text File
|
1986-04-04
|
11KB
|
209 lines
DISKBENCH_11.BIN (MAUG/DL2) 25-Mar-86 (1258 bytes)
DiskBench does simple performance testing using the disk volume from
which it is run. Results are meaningful only relative to those from
competing systems. MDS source code is available (BROwse DBENCH.*).
Please report results to me. Don't move the mouse during the test. On
HyperDrive, run from Startup, which must be more than 1MB in size and not
fragmented (e.g., 1MB+ Startup restored to clean disk). This new version
fixes serious bug in previous one. --Steve Brecher 70001,1011
[Editorial note: what follows is a digest of messages relating to DiskBench.]
-----------------------------
Sb: HD Benchmark
Fm: Steve Brecher 70001,1011
To: All
I wrote a simple disk performance benchmark program which,
along with its MDS assembler source code, is in MAUG/DL2.
The test is designed to measure hardware and disk driver performance, with no
influence from the file system (HFS/MFS) or volume/file/Finder configuration.
The program issues I/O requests directly to the disk driver.
The benchmark consists of three parts:
(1) 100 reads of 32KB of data from the start of the volume;
(2) 100 writes of 32KB of data to the start of the volume;
--the above two tests measure data transfer speed; 32KB was chosen to be a
reasonably large chunk, but not so large that it would cross a cylinder
boundary (thus not requiring any head movement).
(3) 40 iterations of: read one 512-byte block from an offset of 1MB,
followed by read of one 512-byte block from start of volume;
--the above test measures access time, i.e., seek or head movement speed.
The test is non-destructive --
Test (2) writes the data that was read in test (1).
Test (3) is bypassed if the volume size is less than 1MB+512bytes.
The volume tested is that from which the program is run.
On a Mac Plus, make sure disk caching is disabled in the Control
Panel. Also, DO NOT move the mouse while the test is in progress.
The data transfer read/write test results are the time, in sixtieths of a
second, it takes to read/write 32KB, 100 times, from/to the start of the
volume from which DiskBench is run.
The access time test is the time, in sixtieths of a second, it takes to do
forty repetitions of: read 512 bytes from an offset of 1MB into the volume;
read 512 bytes from the start of the volume.
The data transfer test is designed to indicate relative speed of transferring
data between the disk and Mac RAM, with no influence from the software
environment, data/directory/file structure on the disk, or movement of the
disk heads. (The latter is not true with floppies; they have less than 32KB
in a cylinder, so they have to move their heads back and forth during the
data transfer tests.)
The access time test is designed to indicate relative speed of moving the
disk heads to a desired position.
The DiskBench program issues requests directly to the disk driver, bypassing
the file system (bypassing HFS/MFS). It provides a relative measure of the
performance of the disk hardware and disk driver combination. Any disk which
has substantially better results on both tests than another will be faster in
actual use, given the same surrounding hardware and software. I believe (but
cannot prove) that on the Mac (not necessarily on all computers) the data
transfer time is relatively more important than the access time; this is not
to say the latter should be ignored.
My belief is based on impressions and hearsay. Impressions -- listening to
disks in operation; not many long seeks on the Mac. Hearsay -- a report that
MicahDrive is "35% faster" than AST's fast-seeker, and "10-15% faster" than
HyperDrive (which, best I can tell so far, seeks somewhat faster than
MicahDrive). No details supplied with the hearsay, so they could be hogwash.
MicahDrive has the fastest data transfer, but not particularly fast access
time; and I haven't heard of a case where a given application loads faster
from another drive. Excel loads in about 6.5 seconds on MicahDrive (give or
take -- measured by eyeball on adjacent Mac's alarm clock, from Open to
appearance of worksheet).
Files tend not to be too fragmented in my experience, so seeks involved in
resource loading to launch an application are typically over a short distance
-- a cylinder or two. (And many if not most of the small pieces will be in
the same cylinder as the previous.) Differences among drives in
track-to-track times are not as great as differences in longer movements
(e.g., as in the average access times usually quoted). If a disk does become
unduly fragmented, as can happen over time, it can be repaired by
backup/restore.
Suppose it took 50 seeks to load a 100K application. Suppose there was a
difference of 20ms per seek between two drives, but that the faster seeker
transferred each 2K piece at 200KBits/sec while the slower seeker did
450KBits/sec. The fast seeker gains 1.0 second on seeks, but loses 2.2
seconds on data transfer. In this example, the data transfer ratio is
typical of, say, that between MicahDrive and a decent external SCSI; but the
difference in access time is, I think, exaggerated for the typical distances
involved even if the external SCSI's average access time spec is 40ms faster.
(That spec measures time to seek across a big chunk -- a third or half or so
of the surface; I forget exactly how it's computed.)
For the majority of the market, the question is moot. All of the under-$2000
drives have average access times in the same ballpark (65-85ms).
(Current DiskBench results list follows.)
Data transfer Access Tester
---- time ---- time
Reads Writes
400K floppy drive, Apple 8756 11816 N/A S. Brecher
400K floppy drive, Apple 2984(?) 12392 N/A G. Frascadore
400K floppy drive, Apple 2984(?) 12351 N/A R. Perez
800K floppy drive, SS, Apple 8758 11407 N/A S. Brecher
800K floppy drive, DS, Apple 7701 10874 N/A S. Brecher
800K floppy drive, DS, Apple 7523 10913 N/A N. Fong
AST 4000, AST Research 1495 1533 159 KATZ, Mousehole BBS
AST 4000, AST Research 1495 1549 160 KATZ (second drive)
AST 4000, AST Research 1495 1537 169 KATZ (third drive)
DataFrame 20, SuperMac 1319 2233 488 J. Bean
DataFrame 20, SuperMac 1344 2233 487 S. Brecher
Hard Disk 20, Apple 7074 7871 368 N. Fong
Hard Disk 20, Apple 7054 7944 370 KATZ, Mousehole BBS
Hard Disk 20, Apple 9883 6948 368 R. Wiggins
HyperDrive 10, obsolete model 1591 1616 401 S. Brecher
HyperDrive 10, GCC (V2R1) 8000(?) 7982(?) 648(?) H. Conover
HyperDrive 10, GCC (V2R1) 7985(?) 6892(?) 485 R. Perez
HyperDrive 20, GCC (V2R1) 1703 1506 640(?) R. Ford
HyperDrive 20, GCC 1704 1506 241(?) W. Luckie
MacBottom 10, v2.1, PCPC 4159 6897 686 M. O'Connor
MacBottom 10, v2.6, PCPC 4159 6897 608 S. Aronian
MacBottom 20, v2.1, PCPC 4110 6817 601 L. Becker
MacDrive, 10MB Fixed, Tecmar 6017 6719 401 C. Nicholais
MicahDrive 20 AT, Micah 508 507 488 S. Brecher
Quark QC-20 6476 6488 82(?) R. Thacker
QuickDrive external RAMdisk 2411 2479 52 R. Bates
QuickDrive external RAMdisk 2466 2535 33 J. Eugenides
RamStart RAMdisk/Beck-Tech RAM 186 186 N/A G. Frascadore
Warp 20, Warp Nine Engin'rng 14537 14537 321 G. Frascadore
To: Andy Hertzfeld 70167,3430 (X)
Latency is generally included in access time.
I think the benchmarks don't confuse people as much as advertising hype and
vague claims ("blinding speed") posted on networks. And I don't think it's
easy to just measure how long it takes to do things -- your parenthetical
remark about different [contextual factors] on different disks is the big
problem there. Many of the "disk comparisons" I've seen were really
comparisons of the file system (MFS vs HFS).
DiskBench is a cheap (easy to write, easy to run) measurement of the relative
performance of what the consumer is buying when he buys a hard disk --
*provided* that it is understood that the relative numbers do not translate
directly into erceived speed of overall Mac operation, or even overall disk
performance. The only reason they don't translate into the latter is the
existence of the issue we were discussing -- the relative importance of data
transfer vs. access time.
I think the DiskBench results will surprise a lot of people. By and large, I
think those people will be better informed about relative disk performance
than if the results weren't available. Further, I think it will surprise
some vendors, and will lead them to take another look at their driver
software in an attempt to improve it. I know of at least one vendor who
plans to do that as a result of seeing the benchmark. If he succeeds, his
future customers will benefit.
In sum, I don't see how the widespread pre-existing confusion about disk
performance could be made any worse, and I think DiskBench, while very much a
"poor man's benchmark," is a lot better than nothing.
A better benchmark -- one that measured performance in typical use -- is
either much harder to implement or so hard to use (requiring initializing the
disk and comparing only when running the same Apple system software and
identical disk contents ) that it's not feasible without a lot of time and
effort. MacInTouch has designed a reasonably good benchmark of that sort,
but to my knowledge they haven't yet published a results listing including
recently-available disks all running under the same file system, etc. Those
kind of results are expensive to generate.
It *would* be possible to do a vastly improved DiskBench by instrumenting a
driver to record the I/O patterns of one or more end users and then using
that pattern in the benchmark. But that would take a lot longer than the few
hours that DiskBench took to put together...
400K floppy drive, Apple, Sys 3.1.1/Find 5.2:
Test#1 Test#2 Test#3
Internal drive:
Reads 2987 2989 2994
Writes 12359 12444 12466
External Drive:
Reads 2981 2985 2979
Writes 12325 12333 12349
RAMdisk "old" system/Finder:
Reads 184 184 185
Writes 184 185 184
RamStart Sys 3.1.1/Find 5.2
Reads 184 185 184
Writes 185 186 184
The 29xx times for the 400K read tests are a mystery. Floppies cannot go
that fast (the external drive port cannot go that fast). My own test was
done with 128K ROMs.